Phase 3 T3.2: add 13 mutually-exclusive cargo features that pin
simd_profile() to a const at compile time, bypassing the runtime
LazyLock detection from T3.1. One feature per non-Scalar variant of
the SimdProfile enum.

Features (mapping to LLVM target-cpu codenames):
  cpu-gnr         → GraniteRapids    (graniterapids)
  cpu-spr         → SapphireRapids   (sapphirerapids)
  cpu-zen4        → Zen4Avx512       (znver4)
  cpu-cpl         → CooperLake       (cooperlake)
  cpu-tigerlake   → TigerLakeU       (tigerlake)
  cpu-icx         → IceLakeSp        (icelake-server)
  cpu-clx         → CascadeLake      (cascadelake)
  cpu-skx         → SkylakeX         (skylake-avx512)
  cpu-arrowlake   → ArrowLake        (arrowlake)
  cpu-haswell     → HaswellAvx2      (haswell)
  cpu-a76         → A76DotProd       (cortex-a76)
  cpu-a72         → A72Fast          (cortex-a72)
  cpu-a53         → A53Baseline      (cortex-a53)

Mutual exclusion (per integration-plan risk #1: "if a user sets
cpu-spr AND has runtime detection on Zen 4, the binary SIGILLs on
AMX instructions") is enforced via a const assert: each cpu-*
contributes 1 to _PIN_COUNT and the assert fires at compile time if
the sum exceeds one. Verified: enabling cpu-spr+cpu-zen4
simultaneously produces a build error citing the mutex.

Implementation: a const pinned_profile() -> Option<SimdProfile>
walks a cfg cascade and returns the active variant or None. The
simd_profile() function exists in two cfg-gated forms — a runtime
LazyLock variant compiled when no cpu-* feature is set, and a
const-foldable variant compiled when any is set. The LazyLock is
not linked into pinned binaries.

is_pinned() const helper exposes whether compile-time dispatch is
active, useful both for consumer-facing diagnostics and for gating
arch-detection tests that no longer apply when pinning overrides
hardware. Existing x86_target_lands_inside_x86_family /
aarch64_target_lands_inside_aarch64_family tests early-return when
pinned; two new tests (pinning_default_is_off, pinning_consistency)
verify the const + runtime paths agree.

Tests: 2077/2077 lib tests pass under both default and --features
cpu-spr configurations. cargo clippy --lib -- -D warnings clean in
both modes. Mutex compile_error verified by attempting
--features "cpu-spr,cpu-zen4" — fails as expected with the const
assert citation. The default (no feature) path is byte-identical to
the T3.1 runtime detection — no regression risk to the merged #181
work or to the e40f3a3 SimdProfile commit.

Supports step 1 of the TEST-promotion checklist from
.claude/knowledge/td-simd-cpu-dispatch-matrix.md § "TEST verification
checklist": "Boot the binary on the silicon and confirm
simd_profile() returns the expected variant."

The probe prints:
  - Resolved SimdProfile variant + arch/family flags
  - Compile-time pinning status (and pinned variant if active)
  - Every CPUID-derived SimdCaps bit, ticked/unticked
  - ARM heuristic profile when running on aarch64
  - Active compile-time target features (avx512f / avx2)
  - Per-variant matrix-doc cell summary (terse — matrix is source of truth)
  - Runs the same pinning_consistency invariant the unit test checks,
    so a probe deployed on real silicon flags regressions in the cfg
    cascade.

First-hardware results on the build host (Sapphire Rapids):
  - simd_profile() resolves to SapphireRapids ✓
  - amx_tile + amx_bf16 + avx512fp16 all set ✓
  - amx_fp16 unset (correctly NOT promoting to GraniteRapids) ✓
  - GNR-before-SPR ordering invariant verified end-to-end

This is the first end-to-end pass of the e40f3a3 SimdProfile detect
chain plus the 5a3a663 cpu-* pinning machinery on real silicon —
confirms the dispatch axis is functional, not just doc-checked.

Smoke-tested with --features cpu-zen4: probe correctly reports
ACTIVE pinning and Zen4Avx512 as the resolved variant, even on SPR
silicon (pinning intentionally overrides hardware detection).

…losure

Integration plan risk #3 ("Detection robustness across hypervisors"):
CPUID may advertise AMX-TILE while the OS/hypervisor has not enabled
the tile XSAVE state. Without the OS-level check, the dispatch table
routes to AMX kernels that SIGILL at first use.

Fix: SimdProfile::detect() now reads `simd_amx::amx_available()` (the
existing 4-step gate: CPUID → OSXSAVE → XCR0[17,18] → arch_prctl
XCOMP_PERM on Linux 5.19+) and demotes when CPUID and OS disagree.
The GraniteRapids and SapphireRapids arms now require both the CPUID
bits AND `amx_usable`; the Zen4Avx512 arm catches SPR-class CPUID
with locked-down hypervisor XSAVE so dispatch falls to the AVX-512
BF16/FP16 path instead.

Verified on the build host (Sapphire Rapids silicon, kernel 6.18.5):
  - CPUID reports amx_tile=1, amx_int8=1, amx_bf16=1 (all true)
  - simd_amx::amx_available() returns false (hypervisor masks
    XCR0[17,18] or the arch_prctl(XCOMP_PERM) request fails)
  - SimdProfile::detect() correctly resolves to Zen4Avx512, not
    SapphireRapids — the AMX kernels are not reachable from
    dispatch on this OS state.

Without this fix, the e40f3a3 detect path would have resolved to
SapphireRapids on this exact silicon/OS combination, then SIGILL'd
the first time a dispatch table called an AMX kernel. Bug closed
before any consumer was wired to the dispatch table.

The probe binary (examples/simd_profile_probe.rs) gains a new "AMX
gating (CPUID vs OS)" section so the CPUID-vs-OS gap is visible
without reading source. Format mirrors how the matrix-doc cell
summary appears: terse, two lines plus an optional demotion note
when the bits disagree.

Pinned mode (cpu-* cargo features) intentionally bypasses this gate
since pinning is a build-time assertion that the target OS supports
the chosen variant — pinned binaries are non-portable by design.

Tests: 2077/2077 lib pass. cargo clippy --lib clean under default
and --features cpu-spr. Behaviour on hardware with proper AMX
enablement (full prctl path success) is unchanged: SapphireRapids
still resolves to SapphireRapids when amx_available() returns true.